A fundamental construct in secure computing is that of a Trusted Path (TP) [37, 38]. In general, a TP is a high-assurance connection between a computing device and a human. For example, the human can gain assurance that their interaction's with the computer's interface is connected with the intended software on the computing device, and not a malicious look-alike. In contrast, a trusted channel (TC) is an authenticated, integrity-protected, and encrypted connection between two computing devices. The traditional notion of a TP enables a user to communicate from a trusted input device (e.g., a keyboard) in a direct, unmediated manner with a set of trusted commands (implemented by a security kernel or a trusted application). In turn, the trusted commands upon execution display a distinct prompt on the user's terminal that enables the user to verify the activation of the TP. The prototypical example of the use of such a TP is for a secure login application. However, the need for trusted paths is fundamental to security and arises in many other contexts. For example, a trusted path is essential to ensure that the web address of a bank entered by a user is not altered before it reaches the web browser on the user's machine, or that the password for the bank's web site is not revealed to malware residing on the user's machine. Similarly, a trusted path would enable an application to display its output on a user's device with the assurance that its output is not surreptitiously read or modified by malware. From a user's perspective, application output via a trusted path would help assure the user that an application's output is secret and authentic.
A trusted path provides certain basic properties: confidentiality and integrity of exchanged data, authentication of the entities at the two ends of the path, and timely execution of commands (a form of availability) over the trusted path. In addition, a TP should provide three fundamental properties: (1) A TP should be extensible. This means that a user can add additional trusted commands to the TP and remove others, depending upon the needs, sensitivity and integrity requirements of the application area. (2) The TP should be persistent. This means that the user can be assured that the trusted path will always exist. In addition, we can require a stronger property—user-verifiability—that enables the user to verify that the TP is activated at any point. (3) The TP should be recoverable after system compromise. This means that the user can always recover the TP, e.g., by rebooting the security kernel from a trusted source.
Traditionally, the existence of a TP that satisfied all of these properties was predicated on (a) the existence of a penetration-free, security kernel (i.e., non-circumventable, isolated, and verifiable kernel)—the trusted computing base (TCB), and (b) an environment free of malicious software and insiders, who could potentially modify the kernel. The first commercially available secure Unix-style system providing trusted paths was designed by Gligor et al. in Secure Xenix in the 1980's [20, 22]. In today's computing environment, however, neither of these assumptions are reasonable for commercial off-the-shelf operating systems used in large enterprises, where insider attacks represent a significant security risk. Furthermore, connecting such systems to the Internet all but guarantees the presence of malware with full access to all system code and data. (At present, an unprotected host connected to the Internet is infected within twelve minutes on average.) Hence, both the persistence of a TP implemented on such systems and its recoverability would be lost. This observation leads us to formulate another property that we require of the system that implements the trusted path: (4) The properties that are assumed of the trusted path should be formally verifiable. Otherwise, design and implementation errors would leave the TP exposed to attacks by malware and malicious insiders.
Recent TCG proposals [35] that could be used to establish trusted paths can be broadly classified as static root of trust and dynamic root of trust for measurement protocols. Both protocols use a public key cryptosystem to sign and authenticate system software since system boot/re-boot. The processor “measures” the booted code by applying a cryptographic hash function to it and then signs the hash with a hardware-protected private key. A verifying agent can compare the hash to the hash of the expected boot code of which it has a copy, thereby attesting that the booted code was not modified. Upon this base, all trusted software can be attested and thus a user could, in principle, establish and extend the TP to sensitive, high-value applications such as those dealing with financial transactions, cryptographic transactions (e.g., keying and re-keying local and remote systems and applications), command and control applications, and on-line forensic applications even in the presence of malware and malicious insiders.
In the static root of trust for measurement (SRTM) protocol, all system code starting with BIOS, firmware on the adapter cards, bootloader, operating system, and ending with the desired TP application commands is signed and authenticated by the attestation process. Hence, property (4) cannot be achieved as formal verification of millions of lines of source code (comprising the SRTM boot sequence) is beyond the state of the art of current software verification tools. In contrast, the dynamic root of trust for measurement (DRTM) protocol [29, 25] addresses this issue by reducing the trusted base to a manageable size (e.g., the secure loader and selected parts of the BIOS) that could potentially be amenable to formal analysis and verification. However, whether the (1) trusted extensibility, (2) persistence and user-verifiability, and (3) recovery properties of a TP can be achieved by the SRTM and DRTM protocols depends on the strength of the adversary attacks. We first note that, as stated in the TCG specification [35], the Trusted Platform Module (TPM) is not designed to be tamper-proof, i.e. secure against physical attacks. Furthermore, even if the physical tamper-resistance of the Trusted Platform Module (TPM), which stores the private keys used for attestation is assumed, neither the SRTM nor the DRTM protocols can support properties (1)-(3) whenever an insider launches a physical attack against a system—but not against its TPM—left unattended by its owner.
An insider who could access both the Low Pin Count (LPC) bus on a system's motherboard and the BIOS code, which includes the TPM driver, could launch a TPM reset attack [25, 34, 1]. In this attack, the TPM restarts the SRTM boot sequence by loading the hashes of the correct BIOS, adapter-card firmware, bootloader and OS, while the insider-planted, corrupt version of this boot sequence runs. This attack is practical because an insider could obtain the hash values of the correct boot sequence, which the TPM will sign and which would later pass attestation, by passively monitoring the LPC bus [28] and recording the correct hash values of a system identical to that being attacked prior to launching his attack. The correct hash values would be fed to the TPM by insider-modified BIOS during the SRTM boot sequence, as illustrated by recently reported TPM reset attacks [34, 1]. To counter this attack against the SRTM boot sequence, the DRTM protocol uses a new CPU instruction that atomically (i.e., uninterruptably) (1) initializes the CPU to a known trusted state, (2) transfers the code of a secure loader to the TPM via the LPC bus where it is hashed into one of its internal registers, and (3) transfers control to the entry point of the secure loader [2, 24]. The secure loader then measures relevant portions of the BIOS and starts the secure boot sequence. The only effect of a TPM reset attack by an insider would be to restart the secure DRTM boot sequence. However, the DRTM protocol could be subverted by another, equally potent insider attack that would not reset the TPM. Instead, the insider would circumvent the atomicity of the new CPU instruction by injecting signals into the LPC bus pretending to originate from that instruction [34, 1]. This would enable the insider to communicate the hash values of the correct loader to the TPM while his/her modified loader would be run. Thus, an insider-planted boot sequence would initiate the DRTM protocol, pass attestation, and circumvent the properties of trusted path. In principle, regardless of how physically tamper resistant a TPM might be, as long as its LPC bus is exposed to unauthorized outside access, the DRTM protocols can not be secured without relying on built-in secrets that may be vulnerable to new attacks.
More potent, yet non-physical, attacks against the SRTM or DRTM protocols could be launched by insiders and/or malware. These attacks would employ side-channel techniques that would leak the private keys of a tamper-resistant TPM to an adversary. For example, the timing attack of Brumley and Boneh against the private RSA key of Open SSL [5] was recently used in a demonstration attack against the private RSA key of a TPM [34]. In principle, other side-channel attacks, for example based on differential power analysis [27] and fault-injection [4], could be launched against a tamper-resistant TPM to discover its private or secret keys. Not only would such attacks render the trusted path unusable, but more importantly recovery from such attacks by a user (viz., property (3) above) could not be achieved by either the SRTM or the DRTM protocols.
A particularly problematic case of TP recovery arises when the TP design is based on a secret (symmetric) key that is generated by the hardware itself (e.g., using Physically Uncloneable Functions (PUFs) [19]), or stored on an EPROM. In this case, the secret key would become permanently attached to the hardware base and could not be changed. This would violate a fundamental tenet of cryptography that shows that no matter how secure a cipher is, keys must be changed either because their lifetime expires after a certain amount of use or because inevitable attacks in a hostile environment (e.g., side-channel attacks, such as timing and differential power analysis attacks) that could lead to full or partial key discovery must be thwarted. Further, any potential hardware failure, either random or induced by fault-injection attacks, which could compromise key integrity would render the entire system, not just the TP, unrecoverable. We also note that minor variants of this architecture would not improve the situation. For example, if the secret key were stored in programmable registers and would become mutable, access to the key would have to be controlled and updates would have to be performed via some form of TP by a trusted party, if not by the user herself; i.e., the TP could not be bootstrapped without a TP! A similar bootstrapping problem would appear when one would attempt to secure the underlying TPM architecture assumed by the DRTM process by encrypting the communication on the LPC bus between the CPU and TPM: a trusted path would be required to set and reset the secret bus-encryption keys.
Therefore, there is a need for providing trusted paths that satisfy properties (1)-(4) identified above for commercially available systems including those running the Windows and Linux operating systems.
Accordingly, there is a need for establishing a user-verifiable trusted path in the presence of malware and, more particularly, for such methods and apparatuses for use on untrusted computer platforms. Those and other advantages of the present invention will be described in more detail hereinbelow.